썸네일: Unsplash의Paul Hanaoka
출처 : 웹 성능 최적화 기법
웹 성능 최적화 기법(루비페이퍼 사) 도서에 대한 핵심 내용과 지식을 정리한 포스트입니다. 포스트에 올라오는 내용은 도서의 일부이기 때문에 더 자세한 내용이 궁금하신 분들은 출처에서 도서를 구매해 읽어보시는 것을 추천드립니다.
4.4 반응형 웹에서의 이미지 배치 전략
- 모바일 사용자들의 웹 사이트 접속이 증가하면서 웹 사이트 구현 추세의 변화가 생김
- 초기 : 모바일 전용 사이트를 별도 구축(m.(엠닷 사이트))
- 엠닷 사이트의 문제점
- 사이트 하나만으로는 다양한 모바일 기기의 사용자를 만족시킬 수 없게 됨
- 데스크톱용 사이트, 모바일 사이트 별도로 관리되어 유지보수 비용과 시간 소요
- 모바일 사용자 사용성 문제 (데스크톱과 차별화된 환경)
- 위와 같은 문제점으로 반응형 웹 개념이 등장함
- 반응형 웹이란 TV, PC, 태블릿, 스마트폰 등 각종 기기가 제공하는 화면 크기에 맞추어 최적화된 웹 페이지를 제공하는 것
- 기기별로 웹 사이트를 따로 구축하지 않아도 되며, 사용성도 개선됨
- SEO 측면에서도 구글에서 반응형 웹 사이트에 Mobile-Friendly라는 타이틀과 함께 검색 우선순위를 높일 수 있는 환경을 제공해줌
4.4.1 반응형 웹의 문제점
- 반응형 웹 초창기에는 데스크톱과 모바일 기기에서 똑같은 사용자 경험을 제공한다는 측면에서 장점이 있었지만, 성능은 그렇지 못함
- 반응형 웹은 화면 크기가 달라져도 웹 성능이 모두 동일하다는 결과가 나왔고, 모바일 환경에서는 인터넷이나, 기기 성능 등의 문제로 인해 사용자 경험을 오히려 저하시키게 됨
4.4.2 원인은 이미지
- 위와 같은 문제점의 주된 원인은 바로 이미지 크기가 웹 환경에 따라 변하지 않는다는 점이다.
- 반응형 웹을 만들 때는 break point(사이즈가 변화하는 지점)을 정의하고 그에 맞추어 화면을 디자인 한다.
- 미디어 쿼리, 가변 그리드, 유동형 이미지 등의 기술을 적용해서 미디어 쿼리가 사용자의 환경을 감지하고 가변 그리드가 페이지 레이아웃을 구성하면 그 안의 이미지가 자동으로 확장/축소 되면서 화면을 표현
- 개발 단계에서는 우선 고사양 데스크톱, 넓은 화면 모니터, 유선 네트워크로 빠르게 개발 및 테스트를 진행하고, 그 다음 화면 크기를 변경하여 웹 페이지가 작아지는지 테스트한다.
- 이때, 화면이 작아져도 파일의 크기도 작아지지는 않아 웹 리소스들을 과하게 내려받는 현상(over-downloading)이 발생하게 된다.
- over-downloading은 다음 3가지 유형으로 구분된다.
- 내려 받아 줄이기(download and shrink)
- 내려받아 숨기기(download and hide)
- 화면 바깥 부분(below the fold)
내려받아 줄이기(download and shrink)
- 반응형 웹에서는 화면의 크기가 변할 때마다 나타나는 이미지의 가로세로 크기가 달라지므로 고정된 값을 사용할 수 없으므로, 전체 화면 대비 이미지 영역의 비율 값을 사용한다. (유동형 이미지)
- 이때, 유동형 이미지를 사용한다고 해서 실제 이미지가 작아지는 것은 아니므로 브라우저는 큰 이미지를 다운로드해 작게 축소하는 처리를 하고, 실시간으로 줄어든 가로x세로 값을 계산하는 과정이 추가된다.
- 단점으로는 과도하게 큰 이미지를 다운로드 하려고 네트워크를 낭비하며, 축소하는 리소스와 시간이 낭비된다는 점이 있다.
내려받아 숨기기(download and hide)
- 반응형 웹이 데스크톱과 모바일 환경에서 동일한 사용자 경험을 제공하지만, 데스크톱의 화면이 더 큰 만큼 더 많은 정보가 들어가기 마련이며, 모바일에는 불필요한 리소스들이 존재하게 된다.
@media only screen and (max-width: 771px)
.block-related {
display: none
}
- 위 CSS 코드를 예시로 들면 미디어 쿼리를 사용해 모바일 기기 크기를 감지해 display:none을 통해 요소를 숨기는 것을 볼 수 있는데, 브라우저에서는 숨긴다고 알아서 리소스를 다운로드 하지 않는 것이 아니라, 리소스를 먼저 모두 다운 받고 화면에 표현할지 안 할지 만을 결정하게 된다.
화면 바깥 부분 (below the fold)
- fold란 사전적 의미로 접힌 부분을 뜻하며, below the fold는 접혀서 보이지 않는 부분을 의미한다.
- 웹사이트에서는 화면 안쪽 부분이 비즈니스 목표 달성에 있어서 가장 중요한 역할을 하는데, 바깥쪽 이미지들로 인해 페이지 로딩 속도 저하, 화면 안쪽 내용 로딩 속도 저하 등 문제가 발생하여 사용자 경험을 저하시키는 원인이 된다.
4.4.3 반응형 이미지
- 반응형 웹의 단점들은 결국 모바일 환경에서 필요하지 않은 리소스들을 과도하게 다운로드 한다는 문제로 귀결된다.
- 리소스들은 HTML, 자바스크립트, CSS, 이미지를 포괄하지만 그중 약 65%를 차지하는 이미지의 비중이 가장 크다 할 수 있다.
- 이 문제를 해결하는 방법으로는 사용자 환경에 따라 환경에 적합한 이미지를 전송하는 방법으로 해결할 수 있 다. 이런 이미지를 반응형 이미지라고 한다.
4.4.4 반응형 이미지 구현 방법
- 반응형 이미지 구현은 두 가지 측면에서 접근할 수 있다.
1. 프론트엔드 측면에서의 구현
- 미디어 쿼리를 사용해 클라이언트 환경을 파악한 후, 환경에 맞는 이미지 파일을 호출하도록 웹 페이지를 구현한다.
<img>
태그의 srcset 속성이나<picture>
태그를 사용해 표준 방식으로 구현 가능하다.- 과도하게 사용할 경우 프론트엔드 코드가 무거워져 성능에 영향을 줄 수 있다.
srcset과 size 속성
- srcset은 HTML
<img>
태그 속성으로 다양한 환경에 따라 다른 이미지 URL을 지정할 수 있도록 한다.
<!-- srcset 속성을 활용한 예시 -->
<img src="small.jpg" alt="rwd"
srcset="pic-normal.jpg 1x,
pic-retina.jpg 2x">
<!-- size 속성을 활용한 예시 -->
<img src="small.jpg" alt="rwd"
srcset="pic-normal.jpg 200w,
pic-retina.jpg 400w"
size="(max-width: 400px) 100vw, (max-width: 800px) 30vw, 300px"
>
- 1x, 2x는 화소밀도를 나타내며, size 속성을 사용할 경우에는 width 정보를 정의해야 한다.
- 위 코드에서서는 화면의 크기가 0~400픽셀일 때 이미지 사이즈를 전체 뷰포트의 100%로 표현하도록 정의한다.
- vw는 viewport width를 의미하며 1vw는 전체 뷰포트의 1% 크기를 뜻한다.
- 화면의 크기가 401~800픽셀일 경우 전체 뷰포트의 30% 크기로 표현된다.
<!-- picture 태그 -->
<picture>
<source media="(min-width: 45em)" srcset="large.jpg, large-hd.jpg 2x">
<source media="(min-width: 18em)" srcset="med.jpg, med-hd.jpg 2x">
<source srcset="small.jpg, small-hd.jpg 2x">
<img src="small-1.jpg" alt="rwd">
</picture>
<picture>
태그는<img>
srcset의 단점을 모두 보완하며, 내부적으로<source>
태그를 사용해 다양한 이미지 URL을 설정하게 한다.- 이때 미디어 쿼리를 사용해 URL 로딩 조건을 구체적으로 정의할 수 있어, 정의된 조건에 맞는 이미지한 사용하도록 브라우저를 강제할 수 있다.
<picture>
태그를 사용하면 HTML 소스가 다소 길어지고, 모든 브라우저가 지원하지 않는다는 단점이 있다.- https://caniuse.com/?search=picture (2023년 4월 기준 지원 현황)
- polyfill을 이용하여 개발할 수 있다.
2. 백엔드 측면에서의 구현
- 서버에서 클라이언트의 환경에 맞는 이미지를 선택하여 전송하는 방법이다.
- 프론트엔드 코드가 추가되지 않아 성능 향상이 가능하지만, 클라이언트 환경을 어떻게 파악할 지에 관한 문제와 서버 측 프로그램이 추가되어야 하는 번거로움도 있다.
Art direction
- srcset,
<picture>
태그를 사용해도 반응형 이미지가 사용자 환경에 따라 자동으로 변하지 않는다는 점은 해결할 수 없다.- 하나의 원본 이미지에 화면 크기별, 해상도별, 브라우저별로 적합한 이미지를 만드는 노력과 시간이 필요한데, 이를 Art direction이라고 한다.
- 이미지에 따라 보여주고 싶은 대상이 다를 수 있는데, 이럴 경우 단순히 이미지 축소를 하면 원하는 초점이 달라질 수 있어 crop을 이용해서 적합한 이미지를 만들어야 한다.
Client Hints
- Client Hints는 웹페이지를 호스팅하는 서버에서 사용자 환경을 고려해 응답할 내용을 최적화한 후 브라우저에 전달하는 방안이 도입되고 있다.
- 현재 HTTP Working Group에서 구글 주도 하에 Internet-Draft 버전으로 논의를 진행 중이다.
- Client Hints 헤더는 HTTP 헤더 일부로 포함되어 전송되며, 서버는 이 정보를 기반으로 응답 내용을 최적화해 다시 브라우저에 전송할 수 있다.
동작 방식
- 브라우저에서 최초 서버로 HTTP 요청을 보낸다.
- 서버는 응답 헤더에 Accept-CH를 추가해 Client Hints를 지원하고 있음을 브라우저에게 알린다.
Accept-CH : DPR, Width, Viewport-Width
- 브라우저에서는 하위 리소스에 대한 요청부터 아래와 같은 관련 정보를 헤더에 추가해 보낸다.
DPR : 2.0
Width : 320
Viewport-Width : 320
- 서버는 최적화된 이미지를 전송한 후 사용한 DPR 정보를 마지막 응답 메시지로 보낸다.
- 이 DPR 정보는 브라우저가 서버로부터 받은 이미지를 처리할 때 사용된다.
Content-DPR : 1.0
이미지 지연 로딩
- 앞선 방법들은 below the fold 이미지를 최적화하지 못한다는 문제점이 있어, JavaScript를 사용한 지연 로딩 방법이 권장된다.
function loadReal(img) {
if(img.display !=== "none") {
img.onload = null;
img.src = img.getAttribute('data-src');
}
}
<img src="1px.gif" data-src="book.jpg" alt="A Book" onload="loadReal(this)">
- src에는 가짜 이미지가 링크 되어 있고, onLoad 이벤트가 발생할 때 loadReal 함수를 호출한다.
- img Element가 현재 페이지에서 사용자들에게 노출될 수 있는 상태인지 체크하여, 가능한 경우에만 실제 이미지 정보를 링크시켜 다운받을 수 있도록 한다.
- 오픈 소스에는 지연 로딩을 지원하는 다양한 라이브러리 등이 있다.
4.5 적응형 이미지 전략
- 모바일 기기 인터넷 속도는 데스크톱에 비해 느리며 데이터 용량에도 제한이 있기 때문에, 데스크톱과 똑같은 대용량 웹 페이지를 그대로 내려받는 것은 매우 비효율적이며, 이를 해결하고자 서버 측 반응형 웹 접근 방법이 등장했다.
- 서버 측 반응형 웹 접근 방법이란, 서버에서 클라이언트 정보를 파악해 맞춤형 웹 페이지를 생성하여 전송하는 방식을 의미한다.
- 일반 반응형 웹은 서로 다른 기기별 요청에 동일한 대용량의 응답을 다운로드하고, 클라이언트 측에서 화면 크기에 맞게 콘텐츠를 적용시킨다.
- 서버 측 반응형 웹은 기기별 요청을 서버에서 감지하고 각 기기에 적합한 콘텐츠를 만들어 응답한다.
- 적응형 이미지란, 서버 측 반응형 웹 구현시에 필수적인 이미지 호출 방식이다.
4.5.1 적응형 이미지 아키텍처
- 기존 웹 아키텍처와의 차이점
- 요청 클라이언트 정보를 감지
- 클라이언트 맞춤형 데이터를 로딩하는 서버 로직 추가
- 적응형 이미지 아키텍처에서 가장 중요한 부분은 클라이언트 정보를 어떻게 감지하느냐이다. 반응형 웹은 미디어 쿼리를 사용했지만, 서버 측 반응형 웹에서는 클라이언트 정보를 알 방법이 없다.
- Client Hints 스펙이 있긴 하지만 아직 지원하지 않는 브라우저도 다수 존재한다. (2023-4월 기준, 커버리지 약 74%)
- HTTP 요청의 User-Agent 헤더를 통해 클라이언트의 정보를 알 수 있다.
- User-Agent에는 브라우저 정보, 버전, 플랫폼, 시스템, 기타 사용자 정보 등이 담겨 있다.
- 그 외에도 뷰포트, 스크린 크기, 화소 밀도 등 정보는 다음의 여러 가지 유료 솔루션을 통해 정보를 수집할 수 있다.
- DeviceAtlas
- ScientiaMobile/Wurf
- 51degree
4.5.2 기기 정보에 따라 서버 로직 수행
- 관련 정보 수집 후 클라이언트 환경에 맞는 이미지 파일을 링크에 연결한 후, 서버는 다음과 같은 로직으로 실행한다.
- 브레이크 포인트를 사전 정의한다. (여러 브레이크 포인트 별로 개수에 맞는 이미지를 준비)
- 검출된 기기 너비를 추출한다.
- 추출 너비가 브레이크 포인트보다 작다면 그 포인트에 해당하는 이미지 로드
- 일반적으로 브레이크 포인트는 모바일, 태블릿, 데스크톱 3개의 포인트를 설정한다.
4.5.3 브라우저별 이미지 전달
- 브라우저별 이미지는 HTTP 요청의 Accept 헤더를 참고해 결정할 수 있다.
- 단 사파리는 Accept 헤더에 별도 표시를 하지 않아 검출 솔루션에 의존해야 한다.
4.5.4 캐시 고려 사항
- 서버 측 반응형 웹과 적응형 이미지를 구성할 때 이미지를 캐시하는 경우가 많지만, 동일한 URL을 사용해도 사용자 기기에 따라 다른 이미지가 응답될 수 있어 캐시 충돌 현상에 주의해야 한다.
- 캐시 충돌 현상을 피하려면 서버에서 응답 시 Vary 헤더를 활용해 특정 헤더에 따라 콘텐츠가 달라질 것이라고 캐시 서버에 알려줘야 한다.